RKHunter

RKHunter (Rootkit Hunter) is a host-based security scanner for Linux that checks for common rootkits, backdoors, and local system anomalies. It performs file and permission checks, scans for suspicious strings and known signatures, validates system binaries against expected properties, and reports findings for review. It is commonly used as a periodic integrity and hygiene check on servers where lightweight on-host monitoring is desired.

Background and history

As Linux servers became internet-facing and remote administration became routine, attackers began using rootkits and backdoors to maintain persistence after initial compromise. Host-based scanners emerged to detect known rootkit patterns and unexpected changes to critical system areas. RKHunter became widely used because it is simple to deploy, runs from the command line, and can be scheduled to produce regular reports.

Adoption and where it’s commonly used

RKHunter is often used on:

• VPS and cloud servers where administrators want periodic local checks
• Legacy environments without a full EDR/agent-based monitoring stack
• Small-to-medium fleets where quick on-host scanning complements other controls
• Web servers (including WordPress stacks) as part of routine security maintenance

Maintained by

• Maintained by the RKHunter project community.

Best when to use

• You want a lightweight, host-local scanner for routine integrity/anomaly checks.
• You can review and triage scan reports and tune the configuration to reduce false positives.
• You want a scheduled report to supplement other logging and monitoring.
• You need a quick post-maintenance check after updates or configuration changes.

Not suitable when

• You need real-time detection and response with centralized telemetry (use EDR/SIEM agents).
• You require deep behavioral detection or network-based IDS functionality.
• You expect a “set and forget” tool with zero false positives.
• You are investigating an active incident and need strong forensic guarantees (use forensic workflows and trusted media).

Compatibility notes

• Package names and config paths vary by distribution.
• RKHunter relies on baseline properties of files and system configuration; after legitimate system changes (kernel updates, package upgrades), you must update the local baseline to avoid noisy results.
• Some checks may behave differently on container hosts or heavily customized systems.
• Filesystem mount options and distro defaults can trigger warnings that are informational rather than malicious.

False positives are common without tuning

Treat RKHunter output as leads to investigate, not definitive proof of compromise. Validate findings using independent checks before taking disruptive actions.

How RKHunter Works

RKHunter runs a series of checks and compares results against:

• Known rootkit signatures and patterns
• Expected permissions and attributes for critical files
• Local “baseline” metadata stored on the host (file properties, hashes, etc.)

Installation

Debian/Ubuntu

sudo apt update
sudo apt install rkhunter

RHEL/CentOS Stream/Rocky/AlmaLinux/Fedora

sudo dnf install rkhunter

Alpine

sudo apk add rkhunter

Key Files and Locations

Path	Purpose
--
/etc/rkhunter.conf	Main configuration
/var/log/rkhunter.log	Detailed scan log
/var/lib/rkhunter/	Local data and baseline files (distro-dependent)
/usr/bin/rkhunter	Scanner executable

Safe First Run Workflow

1) Update RKHunter data files

sudo rkhunter --update

2) Run a read-only scan and review output

sudo rkhunter --check

For less interactive output (common for SSH sessions):

sudo rkhunter --check --sk

3) Review the log

sudo less /var/log/rkhunter.log

Quickly list warnings:

sudo grep -i 'warning' /var/log/rkhunter.log | less

Establish and Maintain a Baseline

RKHunter compares system state to a local baseline. After legitimate changes (package upgrades, kernel updates), warnings are expected until you update the baseline.

Update file properties database

Run after confirming your system is in a trusted, clean state:

sudo rkhunter --propupd

Baseline safety

Only run --propupd when you trust the host. If the system is compromised and you update the baseline, you may normalize attacker-modified binaries and reduce the tool’s usefulness.

Recommended operational pattern:

• Update packages
• Reboot if required
• Run rkhunter --check
• Investigate warnings
• If changes are expected and verified, run rkhunter --propupd

Common Checks and What They Mean

Finding type	What it usually indicates	Common benign causes
	--	-
File property changes	A critical file changed since baseline	OS updates, package upgrades
Hidden files/dirs	Unexpected hidden items	Application caches, admin scripts
Suspicious strings	Matches to known patterns	False positives in non-standard tools
Permissions warnings	File permissions differ from expected	Custom hardening or distro defaults
Network checks	Unexpected listeners	New services or admin tooling

Practical Use Cases

Routine weekly scan

1. Update signatures/data
2. Run scan
3. Review warnings
4. Update baseline only after verification

sudo rkhunter --update
sudo rkhunter --check --sk
sudo grep -i 'warning' /var/log/rkhunter.log | tail -n 100

After OS updates or kernel upgrades

sudo rkhunter --check --sk

If warnings are due to confirmed package changes:

sudo rkhunter --propupd

Quick validation of unexpected listeners

If RKHunter flags suspicious ports or services, validate with:

sudo ss -tulpen
sudo systemctl --type=service --state=running

Troubleshooting

Frequent warnings after updates

Cause:

• Baseline not updated after legitimate changes

Fix:

• Investigate warnings, confirm they are expected, then update baseline:

sudo rkhunter --propupd

Scanner reports files that do not exist

Cause:

• Distro differences, packages removed, or old baseline references

Fix:

• Update RKHunter data and re-run scan:

sudo rkhunter --update
sudo rkhunter --check --sk

Noise from custom hardening

Cause:

• Custom permissions, mount options, or non-standard paths

Fix:

• Tune configuration in /etc/rkhunter.conf carefully and document changes.

Avoid over-suppressing

Do not blanket-disable large categories of checks. Prefer narrow exclusions with documented justification.

Security Notes

• RKHunter is not a replacement for:

  • Patch management
  • Strong SSH authentication and access controls
  • Host firewall policy
  • Centralized logging/monitoring or EDR

• Treat scan results as indicators that require validation.

• Keep logs protected and ensure log rotation prevents disk exhaustion.

Scheduling

Many distributions install a default cron job or timer. Confirm what is enabled before creating your own schedule.

Check for existing scheduled runs

systemctl list-timers --all | grep -i rkhunter || true
ls -la /etc/cron.* 2>/dev/null | grep -i rkhunter || true

Create a daily scan (example using cron)

Create /etc/cron.daily/rkhunter with executable permissions and a non-interactive command:

sudo tee /etc/cron.daily/rkhunter >/dev/null <<'EOF'
#!/bin/sh
/usr/bin/rkhunter --update >/dev/null 2>&1
/usr/bin/rkhunter --check --sk >/dev/null 2>&1
EOF
sudo chmod 0755 /etc/cron.daily/rkhunter

Reporting

To make scheduled scans useful, route logs to a monitored location or integrate with your alerting path. Avoid exposing scan output publicly.

Quick Reference

Goal	Command
--	-
Update data	sudo rkhunter --update
Run scan	sudo rkhunter --check
Run non-interactive scan	sudo rkhunter --check --sk
Update baseline (trusted host only)	sudo rkhunter --propupd
View log	sudo less /var/log/rkhunter.log
List warnings	sudo grep -i 'warning' /var/log/rkhunter.log